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Abstract 

In  most  working  and  proposed  multiagent  systems, 
the  problem  of  identifying  and  locating  agents  that  can 
provide  specific  services  is  a  major  problem  of  concern. 

A  broker  or  matchmaker  service  is  often  proposed  as  a 
solution.  These  systems  use  keywords  drawn  from 
application  domain  ontologies  to  specify  agent  services, 
usually  framed  within  some  sort  of  knowledge 
representation  language.  However,  we  believe  that 
keywords  and  ontologies  cannot  be  defined  and 
interpreted  precisely  enough  to  make  brokering  or 
matchmaking  among  agents  sufficiently  robust  in  a  truly 
distributed,  heterogeneous,  multiagent  computing 
environment.  This  creates  matching  conflicts  between  a 
client  agent's  requested  functionality  and  a  service  agent's 
actual  functionality.  We  propose  a  new  form  of  interagent 
communication,  called  functional  validation,  specifically 
designed  to  solve  such  matching  conflicts.  In  this  paper 
we  introduce  the  functional  validation  concept,  analyze 
the  possible  situations  that  can  arise  in  validation 
problems  and  formalize  the  mathematical  framework 
around  which  further  work  can  be  done. 

1.0  Introduction 

Several  efforts  are  underway  to  build  multiagent 
computational  grids,  such  as  Globus(Foster  and 
Kesselman  1998),  S  ci  age  n  t  s  ( D  ras  h  an  s  l<  y ,  Joshi  and 
Riceand  1995),  Infospheres(see  http://www.infospheres. 
caltech.edu/).  Such  “grids”  will  be  populated  by  server 
agents  and  services  that  are  available  to  user-defined 
simulations  and  applications/  Kotz  et  al.  1997). 
Computational  resource  agents  will  include  distributed 
components  such  as  databases,  document  repositories, 
mathematical  software  packages,  sensor  feeds,  online 
simulations  and  even  some  hardware  for  computing.  For 
example,  a  grid  agent  may  implement  a  specific 
computational  service  such  as  solving  specialized 
structured  linear  systems  of  equations  or  performing 
complex  data  transformations.  Similarly,  a  grid  agent  may 
offer  data  products  as  a  service,  such  as  an  ocean  model 
performing  real-time  modeling  that  makes  its  state 
estimates  available  upon  request. 
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A  fundamental  capability  required  in  such  a  grid  is  a 
directory  service  or  broker  agent  that  dynamically  matches 
user  requirements  with  available  resource  agents.  On  the 
web,  this  capability  is  provided  by  search  engines  that 
index  web  pages  and  implement  retrieval  services. 
Whereas  humans  are  typically  the  consumers  of  web 
information,  grid  agents  will  be  the  producers  and 
consumers  of  grid  resources  with  humans  occasionally 
steering  or  interpreting  the  computations. 

A  grid  agent  that  needs  a  computational  service,  such 
as  for  example  the  solution  to  structured  linear  system  or  a 
multidimensional  Fourier  transform,  will  locate  the 
required  service  by  consulting  a  distributed  object  request 
broker  agent  or  a  matchmaker  service  agent.  For  example, 
CORBA  is  an  infrastructure  for  implementing  distributed 
applications  and  provides  a  broker  agent  as  a  key 
component/Natan  1995).  An  object  request  broker  agent 
(ORBA)  not  only  locates  a  component  or  object  that 
performs  the  required  service  but  also  mediates 
communications  between  the  client  agent  and  the  service 
agent.  In  standard  terminology,  a  matchmaker  agent  is  an 
ORBA  with  reduced  capability.  A  matchmaker  agent 
merely  locates  remote  agents  or  services  but  does  not 
mediate  communications  between  client  and  server  agents. 
In  the  matchmaker  agent  framework,  a  client  agent  and  the 
remote  agent  that  it  invokes  communicate  directly  once 
their  locations  are  made  known  by  the  matchmaker  service 
agent. 

2.0  The  Functional  Validation  Problem 

The  server  agents  will  advertise  their  services  catalog 
on  ORB’s  or  matchmaker  agents.  Then  just  like  web 
search  engines,  ORB’s  and  matchmaker  agents  will  need 
keywords  and  ontologies  to  specify  agent  services. 
Ontologies  specify  a  domain  and  keywords  specify 
functionality  within  that  domain.  For  example,  ontologies 
are  envisioned  for  signal  processing,  ocean  modeling, 
image  processing,  weather  modeling  and  so  on.  Within  an 
ontology,  keywords  such  as  “Fourier  transform”  and 
“linear  system  solver”  will  have  possibly  domain  specific 
meanings.  Several  systems  have  been  proposed  for 
implementing  such  ontological  matchings  (see  http://logic. 
Stanford.edu/kif/specification.html  and  http://www.es. 
umbc.edu/kqml/). 

Note  however,  there  are  literally  dozens  of  different 
algorithms  for  implementing  Discrete  Fourier  Transforms 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

j^ggg  2.  REPORT  TYPE 

3.  DATES  COVERED 

4.  TITLE  AND  SUBTITLE 

Matching  Conflicts:  Functional  Validation  of  Agents 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Office  of  Scientific  Research, 875  North  Randolph  Street  Suite 
325, Arlington, VA, 22203-1768 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

see  report 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF:  17.  LIMITATION  OF 

18.  NUMBER  19a.  NAME  OF 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE 

unclassified  unclassified  unclassified 

6 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


(Brigham  1988).  Different  algorithms  make  different 
assumptions  about  the  symmetries  of  the  input  vector  and 
order  the  output  in  a  variety  of  ways.  Some  algorithms 
may  be  only  able  to  transform  the  input  vector  of  some 
certain  dimensions.  The  actual  numerical  computations 
carried  out  vary  from  algorithm  to  algorithm  so  that 
different  round-off  errors  are  accumulated  leading  to 
slightly  different  answers.  Moreover  different  numerical 
implementations  of  some  basic  computations  in  an 
algorithm  such  as  Integration  and  Derivation  always  lead 
to  different  computational  speed,  different  accuracy  and  so 
on.  The  same  is  true  of  linear  system  solvers,  other 
numerical  algorithms  and  data  products.  Especially  in 
some  complicated  computation  tasks,  the  possible 
situations  are  more  challenging.  Fox  example,  there  are  a 
lot  of  different  system  modeling  algorithms  developed  for 
different  control  systems  such  as  ARMX  or  ARMAX 
system,  time  variant  or  invariant  system,  noisy  or  non- 
noisy  system,  linear  or  nonlinear  system,  and  so  on.  So  in 
this  case  it’s  more  difficult  for  the  keywords  and 
ontologies  to  precisely  describe  the  real  functionality  of 
the  algorithms. 

Keywords  and  ontologies  cannot  be  defined  and 
interpreted  precisely  enough  to  make  brokering  or 
matchmaking  between  grid  agents’  services  robust  in  a 
truly  distributed,  heterogeneous  computing  environment. 
This  is  the  basis  for  matching  conflicts  between  client 
agents’  requests  and  service  agents’  responses.  Some  form 
of  functional  validation  of  resource  agents  will  be  required. 

Functional  validation  means  that  a  client  agent  presents 
to  a  prospective  service  agent  a  sequence  of  challenges. 
The  service  agent  replies  to  these  challenges  with 
corresponding  answers.  Only  after  the  client  agent  is 
satisfied  that  the  service  agent’s  answers  are  consistent 
with  the  client  agent's  expectations  is  an  actual 
commitment  made  to  using  the  service.  This  is  especially 
important  in  mission  critical  applications.  In  fact  we  can 
find  the  same  idea  of  functional  validation  in  our  daily  life. 
For  example,  a  demo  is  often  used  to  show  the 
functionality  of  some  software. 

Our  ongoing  research  on  agent-based  systems  (see 
http://actcomm.dartmouth.edu  and  http://www.es. 
dartmouth.edu/~agent/)  has  led  us  to  the  conclusion  that 
semantic  brokering  will  not  be  sufficient  to  implement 
truly  distributed,  heterogeneous  multiagent  computing. 
Two  steps  are  required  before  agents  commit  to  each  other: 

1.  Service  agent  identification  and  location', 

2.  Service  agent  functional  validation. 

3.  Commitment  to  the  service  agent. 

These  steps  are  shown  in  Figure  1.  Identification  and 
location  will  be  performed  by  ORBA’s  or  matchmaker 
agents  and  is  already  an  area  of  active  research.  However, 
functional  validation  of  distributed  components  and  agents 
is  a  new  subject  of  research  that  is  essential  for  the  future 


success  of  truly  heterogeneous,  distributed  computing 
grids. 

3.0  An  Example 

Suppose  a  grid  resource  agent  has  been  developed  to 
model  and  predict  a  regional  ocean  circulation.  It  requires 
a  variety  of  grid-based,  distributed  data  products 
(measurement  results  for  example)  and  a  three- 
dimensional  Discrete  Fourier  Transform  to  implement  a 
spectral  method.  The  grid  computation  is  dynamic  -  it  uses 
the  best  available  resources  at  any  time. 

During  runtime,  a  request  is  made  to  an  ORBA  or  a 
matchmaker  agent  for  an  appropriate  DFT.  This  request  is 
made  based  on  keywords  and  possibly  parameter  lists  for 
invoking  the  remote  agent.  The  ORBA  or  matchmaker 
agent  retrievals  its  service  catalog  and  returns  with  several 
candidate  remote  agents  and  specifies  their  returning  value 
structures.  This  is  Step  1.  outlined  above. 

With  this  information,  the  ocean  circulation  model 
must  validate  the  functionality  of  the  remote  DFT  agent, 
typically  written,  maintained  and  updated  by  others.  This 
validation  is  done  at  the  beginning  of  the  run  or  whenever 
a  previously  validated  agent  has  failed  and  a  new  agent 
must  be  located  to  continue  operation.  This  functional 
validation  is  entirely  different  from  issues  of  authentication 
and  certification.  The  performance  and  correctness  of  the 
remote  agents’  sendee  may  have  been  authenticated  and 
certified  by  an  authoritative  procedure  or  person. 
However,  the  actual  functionality  of  the  remote  agent  must 
be  validated  before  the  client  agent’s  ocean  simulation 
commits  to  using  it.  This  is  because  what  was  “correct” 
and  “sufficient”  in  the  eyes  of  the  certifying  authority  may 
not  be  enough  for  the  client  agent  to  conclude  that  the 
sendee  is  “correct”.  Moreover,  the  keyword  description  of 
the  service  may  be  incomplete  or  inconclusive  in  the  eyes 
of  the  client  process. 

The  fundamental  question  asked  by  agent  functional 
validation  is: 

Do  all  parties  involved  in  the  computation  agree 
on  the  actual  agent  functionality? 

Is  the  functionality  of  the  remote  DFT  agent  what  the 
simulation  agent  requested?  This  cannot  be  answered  by 
keyword  matching  or  certification  alone. 

Our  approach  to  functional  validation  is  to  allow  the 
client  agent  to  challenge  the  service  agent  with  test  cases, 
X|,  x2,  ...,  Xk-  The  service  agent  provides  corresponding 
responses/answers,  /r(xi),  fnixf),  ...,/«(Xk).  The  client  agent 
may  or  may  not  have  independent  access  to  the  correct 
responses/answers,  fcfxf,  /cfo),  ...,  /c(xk).  Depending  on 
the  sequence  of  responses,  the  client  agent  may  or  may  not 
commit  to  using  (and  therefore  possibly  paying)  the 
service  agent.  To  implement  such  agent  functional 
validation,  several  questions  need  answering: 


•  How  large  should  k  be? 

•  What  if  fdx)  is  not  known  by  the  requesting  client 
agent? 

•  What  if  the  service  agent  is  fee  based  and  so 
answers,  fR(x),  are  not  given  away  freely  before 
commitment? 

•  How  to  implement  the  validation  process  online? 

These  questions  lead  to  important,  novel  mathematical 
investigations  into  functional  validation. 

4.0  Possible  Agent  Functional 
Validation  Situations 

We  will  formalize  the  functional  validation  program 
for  a  computational  and  data  service  as  follows.  Denote  the 
client  agent's  calling  simulation  by  C  and  the  remote 
agent’s  service  component  by  R.  C  requires  the  evaluation 
of  a  function,  fix),  where  x  is  the  input  parameter. 
Assuming  compatibility  of  input  and  output  parameter 
structures  and  types,  which  has  already  been  checked  by 
ORB  A  or  matchmaker  agent’s  services,  the  remote  agent’s 
service  is  expected  to  provide  fR(x).  There  are  several 
possible  situations  that  can  arise. 

4.1  C  “knows”  fc  (x)  and  R  provides  / R  (x) 

This  is  the  simplest  case.  Here  the  word  “knows” 
means  that  C  itself  is  able  to  know  fdx)  of  the  selected 
samples.  For  example,  the  client  agent,  C,  needs  to 
complete  a  complicated  computation  such  as  a  huge 
dimension  matrix  inverse  operation.  It  assumes  that  C  has 
precomputed  or  otherwise  correct  responses  fdx)  for  some 
simple  test  cases  such  as  some  low  dimension  matrix 
inverse  operations  (which  are  easy  to  be  computed  by  the 
client  agent  itself),  and  that  the  service  agent,  R ,  provides 
responses  fdx).  C  challenges  R  with  these  simple  sample 
inputs.  After  the  service  results,  fR  (x),  are  returned,  we 
must  determine  whether  R  is  implementing  the  “correct” 
service  by  comparing  f  R  (x)  and  fc  (x) . 

Basically  we  can  formalize  these  problems  and  answer 
them  using  PAC  (Probably  Approximately  Correct) 
Learning  Theory  (Kearns  and  Vazirani  1994)  as  a  starting 
point.  We  believe  that  the  semantic  level  brokering  can  be 
used  to  achieve  agreement  about  which  function  class  the 
client  and  service  functions  belong  to.  Traditional  software 
testing  (Beizer  1990)  and  certification  by  other  experts  can 
be  viewed  as  verification  that  the  service  belongs  to  the 
function  class.  Functional  validation  establishes  a  high 
level  of  confidence  that  the  actual  functions  themselves 
match. 

4.2  C  “knows”  fc  (x)  but  R  does  not  provide  fR  (x) 

In  the  above  case,  the  remote  service  agent,  R,  may  not 
be  willing  to  offer  the  exact  results  for  the  challenges  that 


C  poses.  This  is  the  case  when,  for  example,  R  is  a  fee- 
based  service  and  cannot  be  sure  whether  C  will  use  these 
free  responses  in  its  actual  application  but  not  for 
validation  purposes.  So  service  agent  R  could  offer  hashed 
results,  g(fR(x)),  where  g  is  a  secure  hash  function 
specified  by  C,  R  or  an  intermediary.  Fox  example, 
#(/*(*))=  7  ?/*(*),  where  Y  is  a  singular  matrix. 

Because  Y  doesn't  exist,  C  will  not  be  able  to  compute 
fR  (x)  out  from  the  returned  g (fR  (x))  and  Y  ,  i.e. 

Y  -lg(fR  (x))  =  7_1  7T  VK  (x)  =  fR  (x)  . 

By  comparing  g(fc(x))  and  g(fR(x)),  we  can 
formalize  this  case  in  the  same  way  as  4.1  using  ideas  from 
Zero  Knowledge  Proof  theory  (Goldreich  and  Oren  1994). 
Zero  Knowledge  Proofs  have  been  used  to  securely 
exchange  information  between  corresponding  parties 
without  giving  away  any  unnecessary  knowledge.  For 
example,  the  challenge  here  would  be  to  “prove”  that  a 
service  agent  “knows”  how  to  compute  DFT’s  without 
actually  giving  away  any  information  that  could  be  useful 
to  the  client  agent  presenting  the  challenges. 

4.3  C  does  not  “know”  /c(x)  but  R  does  provide 

/«  (*) 

In  the  above,  we  have  discussed  situations  where  C 
“knows”  fc  (x) .  In  fact,  in  some  cases  C  itself  will  not  be 
able  to  “know”  fc  (x).  But  sometimes  C  may  be  able  to 
verify  R’s  service  in  an  “indirect”  way. 

For  example,  C  may  request  weather  forecast  data  from 
a  service  agent,  R.  C  cannot  verify  R's  responses  without  a 
time  delay,  namely  recording  the  predictions  and 
evaluating  them  at  the  time  that  the  actual  weather  is 
known.  This  is  a  simple  case  of  “simulation-based” 
validation.  Let’s  think  about  the  matrix  inverse  operation 
example  again.  Now  assuming  that  C  even  doesn’t  know 

/c(x)  =  x-1  of  the  test  samples,  C  can  still  verify  R's 
service  by  multiplying  the  input  matrix  x  with  the 
returned  f  R  (x)  and  checking  whether  x  ? f  R  (x)  is  equal  to 
an  identity  or  not. 

In  an  more  complex  example,  suppose  the  calling 
component,  C ,  is  controlling  a  plant  with  some  internal 
states  unobservable  by  C  directly.  Based  on  the  observed 
state  and  time  solely,  C  is  not  able  to  observe  or  validate 
directly  the  internal  states  or  parameters,  /c(x),  of  the 
plant.  Instead,  it  consults  a  system  identification  service 
from  the  remote  agent  R.  By  using  the  returned 
parameters,  fR  (x),  in  its  control  policy  and  observing  the 
plant’s  performance,  then  C  can  try  to  verify  whether  R  is 
offering  the  desired  service  by  evaluating  its  own  control 
performance. 


In  this  case,  basically  we  will  try  to  employ  simulation- 
based  learning,  reinforcement  learning,  and  unsupervised 
learning  techniques  for  functional  validation  (Jiang  1998). 


4.4  C  does  not  “know”  fc  (x)  and  R  does  not 
provide  fR(x) 

This  case  can  arise,  for  example,  when  client  agent  C 
requires  a  certain  service  but  the  service  agent  R  provides 
a  related  (derived  or  hashed  values,  for  example)  service. 
This  is  the  most  difficult  situation.  For  the  matrix  inverse 
operation  example  here,  C  doesn't  know  what  fc  (x)  is 
and  just  like  in  case  4.2,  R  may  be  only  willing  to  offer  the 
hashed  result  g(fR(x))=x~l!Y.  But  even  in  this  case, 
like  the  validation  approach  in  the  case  4.3,  C  can  still 
verify  R's  service  by  checking  whether  x  Ig (fR  (x))  is 

equal  to  x?x_1  1Y  —  Y  or  not. 

So  basically  we  believe  this  situation  can  be  reduced  to 
a  combination  of  4.2  and  4.3. 


5.0  A  Mathematical  Model  for  Agent 
Validation  -  PAC  Learning 

In  general,  we  can  formalize  the  problems  arising  in 
the  above  four  situations  and  answer  them  using  PAC 
learning  theory.  Here  the  goal  of  PAC  learning  is  to  use  as 
few  examples  as  possible,  and  as  little  computation  as 
possible  to  pick  a  hypothesis  concept  which  is  a  close 
approximation  to  the  target  concept.  Then  by  the  PAC 
learned  hypothesis,  the  client  agent  can  conclude  whether 
the  service  agent  can  offer  the  “correct”  service. 

For  convenience,  let’s  consider  the  simplest  cases  in 
situation  4.1.  Here  assume  the  input  space  X  is  a  fixed 
set,  either  finite,  countably  infinite,  [0,1]" ,  or  En 
(Euclidean  ^-dimensional  space)  for  some  nil.  For  the 
agent  functional  validation  problem,  we  are  concerned 
with  whether  the  service  agent  can  offer  the  “correct” 
service,  so  we  define  a  concept  to  be  a  boolean  mapping 
c  :  X  ♦  {0,1} ,  with  c(x)  =  1  indicating  that  x  is  a  positive 
example  of  c,  i.e.  the  service  agent  provides  the  “correct” 
service  for  challenge  x,  and  c(x)  =  0  indicating  that  x  is  a 
negative  example,  i.e.  the  service  agent  does  not  offer  the 
“correct”  service  for  challenge  x.  A  concept  class  C  over 
X  is  a  collection  of  concepts  c  over  X  .  So  here  the  single 
unknown  target  concept  is  either  that  the  service  agent 
does  offer  the  “correct”  service,  i.e. 

||/c(x)-/jt(x)||x  ^Y 

(where  y  is  the  allowable  computational  error),  or  that  the 
service  agent  does  not  offer  the  “correct”  service,  i.e. 
\\fcM-fR(x)\\x  1  y  . 


Let  P  be  a  fixed  probability  distribution  on  X  and 
assume  that  examples  are  created  by  drawing  challenges 
independently  and  randomly  according  to  P  .  Define  an 
index  function 

F(x)=  1  ^  \fc  CY)“  /*  CT|  -  Y 

0  otherwise 

Then  the  client  agent  can  randomly  pick  m  samples 
s,„  =  Ch ,  F(X  1 ))  (x2 ,  F(x2 ))  •  •  • ,  (xm ,  F(xm))j  to  learn  a 
hypothesis  hi  H  about  whether  the  service  agent  can 
offer  the  “correct”  service,  where  H  is  the  hypothesis 
space  and  usually  is  the  concept  class  C  itself.  Here  let 
Ac  H  denote  the  set  of  all  learning  functions 

A:  Sm  ♦  H  .  We  claim  that  A|_  Ach  is  consistent  if  its 
hypothesis  always  agrees  with  the  samples,  that  is 
h  =  A(Sm).  Thus  based  on  the  PAC  learned  hypothesis 
which  is  a  close  approximation  to  the  real  target  concept, 
the  client  agent  can  conclude  whether  the  service  agent  can 
offer  the  “correct”  service  with  some  confidence. 

Now  the  problem  is  that  how  many  samples  or 
challenges  are  needed  to  conclude  a  hypothesis  that  is 
enough  approximate  to  the  real  target  concept.  Define  the 
error  between  the  target  concept  c  and  the  hypothesis  h 
as 

error(h)  =  Pr  ob^P  [c(x)  ?  /z(x)] 
where  Pr  oh ,,[.]  indicates  the  probability  with  respect  to 
the  random  draw  of  x  according  to  P  .  Then 
mathematically  we  can  formalize  the  above  problem  as 
follows:  How  large  must  the  number  of  challenges,  m  ,  be 
so  that 

Pr  ob'"  ^rror(h)  <  £  }?  1  —  8 

where  £  is  the  accuracy  parameter  and  8  is  the 
confidence  parameter. 

Blumer  et.al  (1989)  solved  this  problem  with  the 
following  powerful  result 


Theorem  (Blumer  et  al.  1989)  Let  H  be  any  well- 
behaved  hypothesis  space  of  finite  VC  dimension  d 

contained  in  2X  ,  P  be  any  probability  distribution  on  X 
and  the  target  concept  c  be  any  Borel  set  contained  in  X  . 
Then  for  any  0  <  £ ,  8  <  1 ,  given 


m  1 


-4,  2  8  d,  13  , 

max  —log  —  , — log — \ 

£  8  £  £  J 


independent  random  examples  of  c  drawn  according  to  P  , 
with  probability  at  least  1  —  8,  every  hypothesis  in  H  that 
is  consistent  with  all  of  these  examples  has  error  at  most 
£  . 


In  the  above  theorem,  the  Vapnik-Chervonenkis 
dimension  (VC  dimension)  is  a  combinatorial  measure  of 


concept  class  complexity  which  assigns  to  each  concept 
class  C  a  single  number  that  characterizes  the  sample  size 
needed  to  PAC  learn  C  .  See  its  detailed  definition  in 
(Blumer  et  al.  1989). 

Thus  by  determining  the  boolean  concept’s  VC 
dimension  over  X  and  selecting  an  accuracy  parameter  E 
and  a  confidence  parameter  8  ,  according  to  the  above 
theorem,  the  client  agent  can  pick  m  samples  to  PAC  learn 
a  hypothesis  which  is  close  enough  to  the  real  target 
concept,  i.e.  whether  the  service  agent  can  offer  the 
“correct”  services.  However,  with  regard  to  special 
situations  in  the  agent  functional  validation  problem,  for 
example,  sometimes  one  negative  example  is  enough  to 
say  that  the  service  agent  can  not  offer  the  “correct” 
service,  we  believe  that  we  can  get  some  better  results  by 
further  work  on  this  problem. 

6.0  Conclusions 

In  a  multiagent  grid,  a  broker  or  matchmaker  agent  will 
use  keywords  and  ontologies  to  specify  grid  services. 
However  keywords  and  ontologies  cannot  be  defined  and 
interpreted  precisely  enough  to  make  brokering  or 
matchmaking  between  resource  agent  services  sufficiently 
robust  in  a  truly  distributed,  heterogeneous  computing 
environment.  This  creates  matching  conflicts  between 
client  agents  and  service  agents.  Agent  functional 
validation  is  proposed  and  studied  in  this  paper.  It  appears 
to  be  promising  approach  to  resolve  matching  conflicts  in 
distributed  multiagent  grids. 
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